Forwarding Plane Data Communications Channel for Ethernet Transport Networks

ABSTRACT

Described is a process and system for providing an extensible forwarding plane data communications channel adapted to selectively support operations, administration and maintenance (OAM) activity within one or more different domains of an Ethernet transport network. The data communication channel is established using Ethernet protocol data units forwarded within the forwarding plane, between network elements. The Ethernet protocol data units can be Ethernet OAM frames modified to include an OpCode indicative of a maintenance communication channel. The OAM frames are generated at a selected one of the network elements (source), forwarded along the same network path as the Ethernet frames, and terminate at another network element (destination) associated with a maintenance level identified within the OAM frame. The source and destination network elements can reside on a domain boundary using the Ethernet OAM frames flowing therebetween to relay maintenance communications channel messages.

RELATED APPLICATION

This application is continuation of U.S. patent application Ser. No.11/996,561, filed Jan. 23, 2008, which is a national stage entry of PCTapplication no. PCT/US06/35544, filed Sep. 12, 2006, which claimspriority from U.S. provisional application No. 60/716,179, filed on Sep.12, 2005, the entireties of which applications are incorporated byreference herein.

FIELD OF THE INVENTION

The invention relates to communication networks. More specifically, theinvention relates to maintenance entity communications in an EthernetOperation and Maintenance (OAM) domain.

BACKGROUND OF THE INVENTION

With the recent proliferation of computer and communication networks,there is a growing interest in leveraging existing network resources toprovide end users with network connectivity on a demand basis. Thus, asan end user's demand for network resources grows or shrinks, the usermay choose to add or remove network capacity by procuring connectivityfrom other entities. These other entities, generally referred to asoperators, operate and maintain physical network resources. Otherbusiness entities referred to generally as service providers serve asintermediaries between end users and the operators, further simplifyingthe procurement of network resources for the end user. Management of thenetwork requires coordination between these different entities.

FIG. 1 illustrates a conceptual network configuration 100 in whichcommunications between two local area networks (LANs) 106, 112 isaccomplished using a service provider network 118. Such a configurationis useful for interconnecting and extending LANs 106, 112, whichtypically cover a limited geographic region, such as a home or office.With the service provider network 118, the different LANs 106, 112 mayreside on different floors of the same building, within differentbuilding of the same campus, or in different cities, states or evencountries. One such example of extended LAN operations use a techniquereferred to as a virtual LAN (VLAN). Thus, Ethernet frames generated bythe first user 102 can be forwarded through the first LAN 106 across aninterconnecting network 118 and to a second user 114 on the second LAN112. From the end users perspective, there appear to be operating on thesame LAN. Beneficiaries of such interconnected LANs include businessentities, such as large corporations, whose operations span differentgeographical regions.

The service provider network 118 uses transport technology to relaylocal traffic, such as Ethernet frames between LANs 106, 112. Transporttechnologies such as Optical Transport Network (OTN) and SynchronousDigital Hierarchy (SDH) have been developed to provide generic andall-purpose transport containers for moving both voice and data acrossthe network. In order to establish and maintain the underlying networkconnectivity, such transport technologies typically provide a separatechannel for distributed signaling communications and other distributedcommunications in relation to provisioning, managing and monitoringnetwork resources.

For example, the communication channel can be used for order-wire orvoice communications between maintenance entities to coordinate testingand other maintenance activities, such as software downloads. Forconfigurations in which multiple entities are involved providingend-to-end network connectivity, each entity would benefit from such acommunications channel to provision and maintain related networkresources under their control. Preferably, communications on such a datacommunications channel are confined to the managing entity. Thus, eachof the different entities may have a respective data communicationschannel that is isolated from the other entities. Such isolation wouldbe valuable to business operations in which proprietary information maybe shared. Leakage of such information to other entities would beundesirable.

With recent interest in deploying Ethernet as a transport technology, asimilar capability would be beneficial. However, having evolved inenterprise environments, Ethernet is missing this capability as therewas no such need for a separate maintenance channel. Others haveproposed using a dedicated virtual local area network (VLAN) for thepurpose of an Ethernet data communications channel. When differententities are involved in providing end-to-end network connectivity, theyshare the same forwarding plane. Separate VLANS would be required foreach data communications channel needed by Operators and ServiceProviders. Moreover, dedicating the VLANs still does not preventunwanted leakage of information.

SUMMARY OF THE INVENTION

The present invention extends Ethernet OAM functionality by providing adata communication channel within the forwarding plane establishedbetween at least two network addressable devices communicating throughmultiple network elements configured as a network path to support a flowof Ethernet frames. The data communications channel originates at one ofthe network element and is forwarded along the network path terminatingat another of the network elements, such that the data communicationschannel is established therebetween.

In one aspect, the invention features a process for providing a datacommunication channel within a communication network having multiplenetwork elements configured in a path to accommodate a flow of Ethernetprotocol data units between at least two users. Some of the networkelements are associated with different domains. The process includesgenerating at a first network element an Ethernet protocol data unithaving a first symbol indicative of a relationship to the datacommunication channel. In some embodiments, the first symbol is a datacommunications channel operational code (OpCode) provided within anOpCode field of the Ethernet protocol data unit. Also identified withinthe Ethernet protocol data unit is one of the different domains. TheEthernet protocol data unit once generated, is forwarded along the pathof network elements and retrieved at a second network element belongingto the identified domain. The data communications channel is establishedbetween the first and second network elements by the Ethernet protocoldata unit forwarded therebetween. In some embodiments, the protocol dataunit includes another symbol indicative of the functionality of the datacommunication channel. The other symbol can include a sub-OpCodeprovided within a sub-OpCode field of the Ethernet protocol data unit.

In another aspect, the invention features a system providing a datacommunication channel between at least two network elements of multiplenetwork elements configured to accommodate a flow of Ethernet protocoldata units between at least two end users. At least some of the multiplenetwork elements belong to different domains. The system includes anEthernet protocol data unit generator associated with a first networkelement generating an Ethernet protocol data unit having a first symbolindicative of a relationship to the data communication channel and asecond symbol identifying one of the different domains. In someembodiments, the first symbol is a data communications channeloperational code (OpCode) provided within an OpCode field of theEthernet protocol data unit, while the second symbol is associated witha maintenance entity for the identified domain. An Ethernet protocoldata unit receiver is associated with a second network element alsoidentified by one of the different domains. The Ethernet protocol dataunit receiver receives the flow of Ethernet protocol data units andprocesses the generated Ethernet protocol data unit in response to thesecond symbol identifying the associated one of the different domains.The system also includes a data communications channel agent forwardingthe retrieved Ethernet protocol data unit to an application in responseto a first symbol indicating a relationship to the data communicationschannel. The data communications channel is established between thefirst and second network elements by the Ethernet protocol data unitforwarded therebetween.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and further advantages of this invention may be betterunderstood by referring to the following description in conjunction withthe accompanying drawings, in which like numerals indicate likestructural elements and features in various figures. The drawings arenot necessarily to scale, emphasis instead being placed uponillustrating the principles of the invention.

FIG. 1 is a functional block diagram of an exemplary communicationsnetwork.

FIG. 2A is a functional block diagram of an exemplary Ethernet transportnetwork according to an embodiment of the invention.

FIG. 2B is a functional block diagram of a forwarding plane for theexemplary Ethernet transport network of FIG. 2A.

FIG. 3 is a schematic diagram of an exemplary generic Ethernet OAM frameformat.

FIG. 4 is a schematic diagram of an exemplary Ethernet OAM frame formatincluding data communication channel functionality according to anembodiment of the invention.

FIG. 5 is a functional block diagram showing in more detail the internalconfiguration of an exemplary one of the network elements of FIGS. 2Aand 2B according to an embodiment of the invention.

FIG. 6 is a functional block diagram showing in more detail the datacommunications channel agent of FIG. 5 in communication with exemplaryhigher-level entities.

FIG. 7 is a flow diagram of one embodiment of a process for formingEthernet OAM data communications channel frames.

FIG. 8 is a flow diagram of one embodiment of a process for processingreceived Ethernet OAM data communications channel frames.

FIG. 9 is a functional block diagram illustrating an application ofEthernet OAM data communications functionality provided within anexemplary communications network.

FIG. 10 is a schematic diagram of an exemplary Ethernet OAM frameproviding a data communication channel with a port test request message.

FIG. 11 is a schematic diagram of an exemplary Ethernet OAM frameproviding a data communication channel with a reply to port test requestmessage.

FIG. 12 is a schematic diagram of an alternative embodiment of anEthernet OAM frame format including data communication channelfunctionality according to an embodiment of the invention.

DETAILED DESCRIPTION

The following detailed description sets forth numerous specific detailsto provide a thorough understanding of the invention. However, thoseskilled in the art will appreciate that the invention may be practicedwithout these specific details. In other instances, well-known methods,procedures, components, protocols, algorithms, and circuits have notbeen described in detail so as not to obscure the invention.

The invention features a process and system for providing a datacommunications channel within an Ethernet forwarding plane, the datacommunications channel being ancillary to a flow of Ethernet framesbetween the end users. Such a data communications channel isparticularly useful in supporting the coordination of maintenanceactivities between one or more providers of underlying networkresources. The exemplary embodiments described herein relate to a datacommunications channel, referred to as a maintenance communicationschannel adapted to selectively support operation, administration, andmaintenance (OAM) activity within one or more different domains withinan Ethernet transport network.

In brief overview, a data communication channel is established usingEthernet protocol data units forwarded within a forwarding planeestablished between network elements. The Ethernet protocol data unitscan be Ethernet OAM frames modified to include an operational code(OpCode) indicative of a maintenance communication channel. The OAMframes are generated at a selected one of the network elements (source),forwarded along the same network path as the Ethernet frames, andterminate at another network element (destination) associated with amaintenance level identified within the OAM frame. Preferably, thesource and destination network elements reside on a domain boundary. Adata communications agent automatically forwards the data communicationschannel message as required. The data communications channel is thusestablished using the modified Ethernet OAM frames flowing between thesource and destination network elements.

In general, Ethernet OAM protocol and flow identifiers may be used toperform OAM functions in Ethernet networks by enabling network elementsto filter OAM frames based on OAM domain and OAM flow identifiers.Ethernet OAM domains and OAM flow identifiers are described in greaterdetail in U.S. Published Application No. 2005/0099954, filed Jun. 30,2004 and claiming the benefit of U.S. Provisional Application Nos.60/518,910, 60/518,920, 60/518,919, and 60/518,912 all filed on Nov. 10,2003 and U.S. Provisional Application No. 60/535,018 filed on Jan. 7,2004, all the content of which are incorporated herein by reference.

FIG. 2A illustrates an exemplary point-to-point Ethernet transportnetwork 200. The network 200 includes a series of network elementsinterconnected by physical-layer links 210. For illustrative purposes,each of the network elements is shown as a bridge, although othernetwork elements, such as a router can also be used alone or incombination with bridges. Network segments 210 represent theinterconnections between the different network elements B2, B3. One ormore of these segments 210 can include wires, fiberoptic cables,wireless links, and combinations thereof. Ethernet frames received atone end of the network 200 are forwarded through the network 200 exitingat the opposite end. Media Access Control (MAC) addresses within theEthernet frame are used for ultimate delivery of the frame to itsintended recipient (e.g., a computer connected to one of the edgebridges B1, B9 through a LAN).

Such a point-to-point Ethernet connection may be configured as a VirtualLAN (VLAN) between end users coupled to the edge bridges B1, B9 ateither end of the network 200. Thus, an end user connected through afirst LAN to one end of the network 200 communicates with entities on asecond LAN located at the other end of the network 200 as though theywere sharing the same LAN. Transport of Ethernet frames across thenetwork 200 is handled by a service provider 202. The network resourcesprovided by the same provider 202 and participating in the connectivityis referred to herein as the service provider domain 202.

The edge network element B1, B9 are referred to as customer equipmentsuggesting that they are managed by the end user rather than the serviceprovider 202. Such edge network elements B1, B9 represent natural pointsof demarcation at which the service provider 202 delivers networkconnectivity. Continuing with this example, the serviced provider 202may choose to provide the network connectivity by engaging networkresources from one or more operator networks, Operator A 204 andOperator B 206. The service provider 202 includes provider businessentities, such as RCN. Likewise, the Operators 204, 106 can include suchbusiness entities as VERIZON and AT&T.

The level of service provided by the service provider 202 to thecustomer is typically defined within a document commonly referred to asa Service Level Agreement. The service provider 202 may also have asimilar agreement in place with each of the operators 204, 206. Thus,the customer equipment B1, B9 is managed by an entity referred to as acustomer. The service provider network 202 is managed by an entityreferred to as the service provider. Likewise, the operator networks204, 206 are managed by entities referred to as operators.

With the service level agreement in place, the service provider 202provides the customer with a single point of contact for all billing andtechnical issues regarding the network connectivity. The serviceprovider, in turn, deals with each of the different operators 204, 206independently to obtain respective sub-network connectivity. With eachof the entities (customer, service provider, and operator) responsiblefor different network domains, there is a need to monitor the differentdomains independently. Beneficially, the Ethernet OAM protocol providessuch a feature.

Each of the bridges B1 through B9 has at least two ports P1, P2, whichare each interconnected through a physical communications link to arespective port on an adjacent bridge. A link between bridge B3, port P1and bridge B2, port P2 is referred to as an internal link 210; whereas,a link between bridge B2, port P1 and Bridge B1, port P2 is referred toas an edge link 208 a.

Although not shown here, it would be possible for one or more of thelinks to include additional communications equipment. For example, theedge link 208 c between the first and second operator domains 204, 206may include yet another domain, such as a long haul carrier (not shown).Operator A and B domains 204, 206 may represent metro networks indifferent cities (e.g., VERIZON and AT&T), interconnected by a long-haulcarrier (e.g., SPRINT).

FIG. 2B is a schematic diagram of the logical configuration 220 of thenetwork bridges B1 through B9 (FIG. 2A) identifying Ethernet OAMconfiguration items defined therein. A dotted line represents a path 222through which Ethernet frames flow (i.e., a forwarding plane). The path222 extends horizontally through the Ethernet transport network 200(FIG. 2A), with Ethernet frames entering at either end and progressingalong the path 222 toward the opposite end. At each of the bridges B1through B9, the logical path 222 includes two vertical diversions 224A,224B (generally 224), each associated with a respective one of the portsP1, P2. The vertical diversions 224 can be loosely divided intodifferent strata, each being associated with one or more of the networkentities. Symbols indicative of OAM configuration items are respectivelyplaced along the vertical diversions at the appropriate stratum asdescribed in more detail below.

Ethernet OAM refers to Maintenance Entities (ME) as those entities thatrequire management. For example, the exemplary first operator domain 204includes bridges B2, B3, B4 (FIG. 2A) representing one such maintenanceentity. Similarly, the second operator domain 206 includes bridges B5through B8 representing another such maintenance entity. The serviceprovider network 202 (FIG. 2A) represents yet another maintenance entitythat includes the domains of both of the operators 204, 206. As shownand described, the operator maintenance entities 204, 206 are said to benested within the service provider maintenance entity 202. Formultipoint connectivity, Ethernet OAM describes the concept ofMaintenance Entity Groups (MEGs) as including different MEs. Forpoint-to-point Ethernet connectivity, a MEG contains a single ME.

Ethernet OAM refers to Maintenance Entity Group End Points (MEPS) asmarking the end points of an Ethernet MEGs. MEPs are capable ofinitiating and terminating Ethernet OAM frames for fault management andperformance monitoring. The OAM frames are distinct from the flow ofEthernet frames. Thus, the Ethernet OAM frames are added to theaggregate of the flow of Ethernet frames and it is assumed that they aresubject to the same forwarding treatment as the non-OAM Ethernet framesbeing monitored.

The triangle symbols located along the flow path 222 represent MEPs 230a through 230 o (generally 230) that have been configured within thevarious network bridges B1 through B9 (FIG. 2A). As shown, some bridgesinclude multiple MEPs 230 within the same port 224. This can result fromnetwork configurations having nested domains. Thus, each of thedifferent MEPs 230 in a bridge configured with multiple MEPs 230 isassociated with a respective administrative domain (e.g., customer,service provider, operator). Ethernet OAM provides for different MEGlevels to allow for the identification and separation of OAM frame flowsamong the different MEs. Displacement of the MEP 230 along the verticaldiversions 224 of the flow path 222 corresponding to an associated MEGlevel. The lowest layers correspond to an Ethernet physical layer 226,whereas the higher layers correspond to other logical layers 228including link layer and transport layer.

Horizontal lines drawing between pairs of MEPs 230 represent a flow ofEthernet OAM frames therebetween. Thus, OAM flows can be inserted andextracted at reference points (i.e., MEPs) within the network. EthernetOAM frames are formed at source flow points and retrieved at terminationflow points. According to an Ethernet OAM embodiment of the invention,the OAM flows are initiated at one MEP 230 and terminate at another,each of the MEPs 230 residing within the same MEG level. Thus, each ofthe flows is associated with one of the MEG levels.

A first OAM flow 232 between MEP 230 a and MEP 230 b (points A and B)can be referred to as a customer UNI-UNI flow 232. This designationreflects that the reference points (MEPs 230) reside on the customerside of the UNI 212 a, 212 b. A second OEM flow 234 between MEP 230 cand MEP 230 d (points C and D) can be referred to as a provider UNI-UNIflow 234. This designation reflects that reference points (MEPs 230)reside on the provider side of the UNI 212 a, 212 b (FIG. 2A). Other OAMflows 238 a, 238 b (generally 238) can be referred to as anintra-operator flow 238 because OAM frames flow between reference pointson the boundary of an operator network 204, 206. Namely, OAM frames of afirst intra-operator flow 238 a transit between MEP 230 e and MEP 230 f(points E and F), each located at the boundary of Operator A network204. Similarly, OAM frames of a second intra-operator flow 238 b transitbetween MEP 230 k and MEP 2301, each located at the boundary of OperatorB network 206.

Yet another OAM flow 236 can be referred to as an inter-operator flow236 because OAM frames flow between reference points on the boundariesof two adjacent operator networks 204, 206. Namely, OAM frames of theinter-operator flow 236 transit between MEP 230 i of Operator A bridgeB4 and MEP 230 j of Operator B bridge B5. Still other OAM flows 239 a,239 b, 239 c refer to Ethernet physical layer OAM flows. Thisdesignation reflects that the reference points (MEPs 230) reside withinthe physical Ethernet layer.

In general, Ethernet OAM flows can be established between any flowpoints as required. Advantages of establishing OAM flows as describedabove is that each of the customer, service provider, and operators canuse Ethernet OAM facilities to monitor performance and detect or verifyfaults within its respective domain. Thus, if an end user or customerdetects a loss or degradation of network connectivity, they can useEthernet OAM to identify which side of the UNI is responsible for thesource of the loss or degradation of service. If the customer determinesthat the source lies within the network, the service provider iscontacted and uses the provide uses an OAM flow to verify the customer'scomplaint. Likewise, each of the operators uses a respective OAM flowand an inter OAM flow to further isolate the source of any problem. Datacommunication channels supported within the Ethernet forwarding planefacilitate management of the underlying connectivity without dedicatingother network resources not already participating in the forwardingplane.

The circle symbols 242 located along the flow path 222 represent MEGIntermediate Points (MIPs) 242. A MIP 242 represents an intermediatepoint in a MEG, which is capable of reacting to some Ethernet OAMframes. According to the Ethernet OAM protocol, MIPs 252 neitherinitiate OAM frames, nor do they take any action to the transit Ethernetflow.

Ethernet OAM standards currently under development do provide forlimited resources to assist in performance monitoring and faultdetection/verification. These resources include: an Ethernet ContinuityCheck function (ETH-CC) that can be proactively issued by one MEP 230 todetect any loss of connectivity to another MEP 230; an Ethernet Loopbackfunction (ETH-LB) to verify connectivity with a MIP 242 or peer MEP(s)230; and an Ethernet Link Trace function (ETH-LT) to retrieve adjacencyrelationship between a MEP 230 and a remote MEP 230 or MIP 242 and forfault localization by comparing the sequence of MEPs 230 and/or MIPs 242with that expected from the forwarding plane.

FIG. 3 is a schematic diagram of a generic Ethernet OAM frame 300′,similar to that described in a September 2005 draft version of theInternational Telecommunication Union publication entitled “DraftRecommendation Y.17ethoam—OAM Functions and Mechanisms for EthernetBased Networks.” In general, the frame includes a number of fieldsarranged into a frame header portion 301 and an Ethernet OAM ProtocolData Unit (PDU) 302. The fields of the Ethernet frame 300′ including anEthernet OAM PDU 302 are described in Table 1A.

TABLE 1A Fields of the Ethernet OAM Frame/PDU Ethernet OAM FieldDescription DESTINATION MAC 306 6-Octet field identifying a uniquemulticast address or a unicast address of a MEP 230 (FIG. 2B) SOURCE MAC308 6-Octet field typically identifying the unicast MAC address of thesource MEP generating the frame 300′ ETHERTYPE (VLAN) 310 Optional2-Octet field used as a forwarding plane service identifier at the ETHlayer VLAN 312 Optional 2-Octet field identifying a VLAN Tag ETHERTYPE(OAM) 314 2-Octet field identifying a unique Ethernet type thatidentifies OAM frames VER 316 4-bit field identifying OAM protocolversion ME LVL 318 4-bit field identifying the administrative domain(i.e., the maintenance entity level) of the OAM frame (e.g., ranges from0 to 7: ranges 0-2 identify operator domains; ranges 3-4 identifyprovider domains; and ranges 5-7 identify customer domains). OPCODE 3201-Octet field identifying the type of OAM frame (e.g., ETH-CC, ETH-LB,and ETH-LT) HDR LEN 322 2-Octet field identifying the number of bytes ina fixed- length header TRANSACTION/SEQUENCE 4-Octet field supplied byoriginator of OAM request IDENTIFIER 326 and copied in the OAM reply,the semantics of this field being dependent upon the OPCODE TRANSMISSION4-Octet field identifying the time at which the OAM TIMESTAMP 324 framewas transmitted from originating MEP HEADER EXTENSIONS 328 4-Octet fieldprovided for future extensions

The OAM PDU 302 also includes an application-specific portion 304associated with an OpCode function identified by the OPCODE 320 field.The application-specific portion can be further divided into differentfields, such as the exemplary fields described below in Table 1C.

TABLE 1C Application-Specific Fields of the Ethernet OAM PDU EthernetOAM Field Description MEG ID TLV optional variable-length used for othertype, length, and 330 value associated with the Maintenance Entity GroupID OTHER TLVs optional variable-length field used for other types, 332lengths, and values as may be required (e.g., a service ID type, length,and value included when frame associated with service instance)

Examples of the values that may be assigned to the OPCODE field 320referenced above are listed in Table 1B. These examples relate to thoseprovided within the September 2005 draft version of the “DraftRecommendation Y.17ethoam—OAM Functions and Mechanisms for EthernetBased Networks.”

TABLE 1B Exemplary Ethernet OAM OPCODE Values OPCODE Description ValueIntrusive Loopback Request (0x00) Intrusive Loopback Release (0x01)Intrusive Loopback Reply (0x02) Non-Intrusive Loopback Request (0x03)Non-Intrusive Loopback Reply (0x04) Path Trace Request (0x05) Path TraceResponse (0x06) Connectivity Check (0x07) Performance Monitoring Request(0x08) Performance monitoring Reply (0x09) Alarm Indicator Signals(0x0A) Remote Defect Indicators (0x0B) Vendor Specific for extension ofOAM (0xFF) functions in proprietary ways

The present invention extends the Ethernet OAM frame functionality byproviding a specific Data Communications Channel (DCC) OpCode pair. AnOpCode DCC value signals that the Ethernet OAM frame includes a messagerelated to the data communications channel. A new field is also providedwithin the application-specific portion 304 of the Ethernet OAM PDU 302providing a sub-OpCode. The sub-OpCode can be used in combination withthe DCC OpCode to extend the functionality of the data communicationschannel without the need for changes within the standardized features ofthe Ethernet OAM frame.

FIG. 4 is a schematic diagram of another Ethernet OAM-enabled frame 300″including within the OPCODE field 320 (FIG. 3) a value or symbolidentifying a Data Communication Channel (DCC) 340 OpCode. Ethernet OAMframes 300″ including the DCC 340 OpCode will be routed between MEPs 230(FIG. 2B) and used to establish a data communications channeltherebetween.

A MEP 230 recognizing a DCC 340 OpCode within an Ethernet OAM frame 300″passes the frame to a DCC agent 244 (FIG. 2B). The DCC agent 244examines the DCC 340 OpCode and any related sub-OpCodes to determine therelated functionality. Upon determining the functionality, the DCC agent244 automatically forwards the Ethernet OAM frame 300″ to an appropriateapplication agent. The application agent, in turn, processes the messageand, if required, generates a reply message. The application agentautomatically forwards the reply message back to the DCC agent 244,which passes it to the MEP 230 for standard Ethernet OAM frameprocessing. Thus, such a reply message results in the generation of oneor more Ethernet OAM frames 300″ sent to the originating MEP 230.

In some embodiments, as shown, the OTHER TLVs field 332 of the standardEthernet OAM frame 300′ (FIG. 3) includes a data communicationssub-OpCode type, length, and value field 342. Some exemplary uses of thesub-OpCode field 342 are included in Table 2.

In some embodiments, a single OpCode is provided together with asub-OpCode as described above. Beneficially, a different sub-OpCode isused for each of the functionalities supported between the differentmaintenance entities. In other embodiments, separate OpCodes areprovided for the different functionalities supported between thedifferent maintenance entities.

TABLE 2 Exemplary Sub-OpCodes for Ethernet OAM DCM/DCR Sub-OpCodeDescription Circuit Test Checks status information associated with aspecified circuit Circuit Configuration Get Retrieves configurationinformation associated with a specified circuit Report PortConfiguration Get Retrieves configuration information associated with aspecified remote port Circuit Configuration Set Sets configuration of aspecified circuit Remote Port Configuration Set Sets configuration of aspecified remote port MCN Provides a TMN required maintenancecommunication network to transport management messages between TMNcomponents SCN Provides Automatic Switched Transport Network (ASTN)required signaling-communication network to transport signaling messagesbetween ASTN components Remote ATM Management For example, in an ATMenvironment, populating Interim Local Management Interface (ILMI)functions allowing UNI management information to be exchanged betweenUNI management entities, etc.

The DCC 340 OpCode is provided within the Ethernet OAM PDU 302; whereas,the sub-OpCode is provided within the application specific portion 304of the Ethernet OAM PDU 302. Such a configuration provides extensibilityto the DCC 340 by allowing a user to identify new and variousapplications without having to first obtain approval from a standardsbody.

FIG. 5 is a schematic diagram showing in more detail a functionalrepresentation of the bridge B2 situated at the UNI (FIG. 2A) accordingto an IEEE Standard 802.1D-2003 “baggy pants” model. Each leg 224 a, 224b (generally 224) of the bridge 400 represents a different one of theports P1, P2. Each leg 224 is segmented into different regionscorresponding to internal configuration and protocols supported by therespective port P1, P2. The bottommost protocol regions shown in eachleg 402 a, 402 b (generally, 402) represent the physical-layerprotocols, such as ETH layers. Each of these physical layer protocols402 is in communication with a respective Ethernet link segment 208,210.

Above the physical layers 402 a, 402 b are link layer protocols, such asthe IEEE 802.1Q Tagging “Y” protocol 404 a, 404 b. The Ethernet OAMprotocol is included within the link-layer protocol. In particular, theEthernet OAM protocols are implemented as “shims.” Thus, the standardEthernet protocol processes all Ethernet frames. OAM Ethernet framesreceive additional processing, as may be required, by the Ethernet OAMprotocol shims. In particular, the bridge B2 includes within each leg224 a downward-facing shim 406 a, 406 b (generally 406) facingexternally from the respective port and an upward-facing shim 408 a, 408b (generally 408) facing internally from the respective port. At eachport P1, P2, the MEPs 230 can be configured in either shim 406, 408, asrequired. The MIPs 242 can be configured between the upward and downwardshims 406, 408 of each leg, as required.

Additionally, the bridge B2 can be configured with higher-layer entities411 (applications) that are accessible through Logical Link Controllers(LLCs) 414. A number of LLCs 414 are provided, such that for each port224, a respective one of the LLCs 414 is associated with the MAC layer404 and each of the shims 406, 408. The bridge B2 also includes a relayfunction 410 for relaying Ethernet frames from one port to the other toperform a forwarding function for Ethernet frames within an Ethernetflow.

Also shown are the MEPs 230 and MIPs 242 originally identified with theOperator A bridge B2 shown in FIG. 2B. Associated with the first portP1, first and second outward-facing MEPs 230 j, 230 h are configuredwithin the downward shim layer 406 a. First and second inward-facingMEPs 230 e, 230 c are configured within the upward shim layer 408 a, anda first MIP 242 b is disposed between the two shim layers 406 a, 408 a.

Associated with the second port P2, a third outward-facing MEP 230 m isconfigured within the downward shim layer 406 b. There are noinward-facing MEPs configured within the upward shim layer 408 b, and asecond MIP 242 c is disposed between the two shim layers 406 b, 408 b.Each of the MEPs 230 and MIPs 242 can be configured via a managementplane and/or control plane (not shown). Additionally, the managementplane configurations can be carried out through manual localadministration of each device or via network management systems. As partof the configuration process, each of the MEPs 230 and MIPs 242 is givena ME level. MEPs 230 within an operator or provider domain wouldgenerally have a level associated with the respective operator orprovider. However, an outward facing MEP 230 located at an edge betweenanother entity, may have a common level negotiated between the twobounding entities.

The bridge B2 also includes a DCC agent 244 in communication with theMEPs 230. Ethernet OAM frame 300″ received by the MEP 230 c thatincludes a DCC OpCode 340 (FIG. 4) are forwarded to the DCC agent 244for further processing. Referring to FIG. 6, a DCC agent 244 receivinginformation from an Ethernet OAM frame 300″ automatically forwards thereceived OAM information to a higher-layer entity 412. In someembodiments, such forwarding occurs in response to the sub-OpCode value.Some examples of higher-layer entities that can be used in such a datacommunications channel include a remote test application 430, anorderwire application 422, a Telecommunications Management Network (TMN)application 424, and other applications 426.

TMN refers a protocol model for managing open systems in acommunications network. In particular, the model identifies fourfunctional layers of network management including: (i) BusinessManagement for handling items including billing, account management andadministration; (ii) Service Management; (iii) Network Management forproviding oversight services to aid in managing major sections of thenetwork; and (iv) Element Management for providing oversight andcoordination of the services provided by groups of network elements.

Beneficially, the higher-layer entities or applications used incombination with the DCC can be accessed by the responsible maintenanceentity associated with the domain. Thus, operators at either boundary ofan operator network or domain can establish a data communicationschannel within the Ethernet forwarding layer by passing Ethernet OAMframes having a DCC OpCode. Such frames can be originated and retrievedautomatically by other applications running on either end of the datacommunications channel.

By way of illustrative example, a voice orderwire application at a firstMEP receives a voice signal, digitizes the voice signal, and partitionsthe digitized voice into ordered segments. The orderwire applicationworks with the source MEP to generate a stream of Ethernet OAM messages,each including a DCC OpCode, a voice orderwire sub-OpCode, and arespective segment of the digitized voice. The Ethernet OAM messages areforwarded through the Ethernet forwarding plane to a selected MEP. Atthe recipient MEP, a DCC agent forwards the received messages to acorresponding voice orderwire application that recognizes the voiceorderwire functionality, unpacks the digitized voice segments, placesthem in order, and translates the digital voice message into an analogvoice signal.

Moreover, with the layering provided by the Ethernet OAM protocol, it ispossible to establish multiple such DCCs for one or more maintenanceentities at a single bridge B2. Thus, referring again to FIG. 2B, theexemplary bridge B2 can support a first DCC between points C and D forthe service provider 202, a second DCC between points E and F for therespective Operator A 204, and a third DCC between points G and Hregarding the UNI. One or more of these DCCs can be used concurrentlythrough Ethernet OAM frames flowing within the forwarding plane, suchthat the first DCC between points C and D and the second DCC betweenpoints E and F can exist simultaneously within the same forwardingplane.

FIG. 7 is a flow diagram of one embodiment of a process 500 forforwarding a data communications channel using Ethernet OAM protocolbetween two MEPs 230. An Ethernet OAM frame is generated at a source MEPlocated within transit path of Ethernet frames at Step 505. This can beaccomplished with DCC generator, such as a DCC application associatedwith the source MEP for generating the Ethernet OAM frames having a DCCOpCode value and optionally including a DCC sub-OpCode indicatingfunctionality associated with the data communications channel. The DCCframe generator also identifies a ME level associated with the DCCtermination MEP at Step 510. The suitably generated message is routedusing standard Ethernet OAM routing through the Ethernet forwardingplane to the DCC termination MEP at Step 515. At the DCC terminationMEP, Ethernet OAM frames associated with the DCC are recognized at Step520 and forwarded to an application agent associated with the identifiedfunctionality at Step 525.

FIG. 8 is a flow diagram of one embodiment of a process 550 forreceiving Ethernet OAM data communications channel frames. An Ethernetframe in the forwarding plane is received at one of the network elementsof an Ethernet transport network at Step 555. In processing the receivedEthernet frame through the protocol stack, the Ethernet type field isinterpreted at Step 560. If the frame received is recognized at Step 565as an Ethernet OAM frame by an Ethertype OAM, the frame is furtherprocessed within the OAM shim at Step 570. Otherwise, the Ethernet frameis processed according to normal Ethernet protocol at Step 575.

When processing an Ethertype OAM frame, the message is sequentiallyprocessed within the bridge according to the order in which the MEPs 230(FIG. 5) have been configured. At each MEP 230, the ME level of thereceived frame is compared to ME level of the MEP 230. Should there be amatch at Step 580 with any of the MEPS, the Ethernet OAM frame isfurther processed by interpreting the OpCode field at Step 585.Otherwise, the frame is passed along to any other MEPs and processedaccording to normal Ethernet OAM processing at Step 598 (e.g., forwardedalong to another network entity). If the OpCode is recognized as a DCCOpCode at Step 590, the Ethernet OAM frame is forwarded to a DCC agentfor further processing at Step 595. This can include forwarding theEthernet OAM frame by the DCC agent to an appropriate applicationidentified by the DCC OpCode value and/or any sub-OpCode values.Otherwise, the Ethernet OAM frame is processed according to normalEthernet OAM frame processing at step 598. In some embodiments, theprocess includes an additional step (not shown) of automaticallygenerating a reply Ethernet OAM DCC message in response to processingthe received DCC message.

A functional block diagram of an exemplary network configuration isshown in FIG. 9 by which digital subscribe line (DSL) users remotelyaccess the Internet. In particular, end-user DSL subscribers accessesthe Internet through DSL modems 602 a, 602 b (generally 602). The DSLmodems 602, in turn, are coupled to an access network 606 through alocal loop wiring 603. The local loop wiring 603 terminates each DSLmodem 602 to an access node, such as a digital subscriber line accessmultiplexer (DSLAM) 616. The DSLAM 616 multiplexes the multiple DSLsubscribers connected thereto onto a high-speed Ethernet backbone 617,which may include one or more internal network bridges 614. The accessnetwork 606 also includes a broadband network gateway 612 also coupledto the Ethernet backbone 617.

The broadband network gateway 612 is further coupled to the Internetthrough an Internet Service Provider (ISP) network 604. The ISP network604 can include an access device, such as an Authentication,Authorization, And Accounting (AAA)/policy server 610. The AAA/policyserver 610 communicates with DSL subscribers through the broadbandnetwork gateway 612 to manage access to the ISP network 604. Forexample, the AAA/policy server 610 may be used to establish apoint-to-point protocol link with the DSL subscriber providing access,once authenticated and authorized, to the Internet through an IP router608.

It is common for the access network 606 to include a separatemaintenance channel 618 through which the broadband network gateway 612,typically a Broadband Remote Access Server (BRAS) 612, can request someform of line testing. For example, the BRAS 612 can request line testingto ensure sufficient connectivity to the DSL subscriber to verify theintegrity of the access network 606. Beneficially, the maintenancechannel 618 can be provided by the data communications channel extensionto Ethernet OAM protocol described herein without the need for separatededicated network resources.

A MEP in the access node 616 receives Ethernet OAM frames arriving viathe maintenance channel 618 configured between the access node 616 andthe BRAS 612. The Ethernet OAM frames supporting the maintenance channel618 include the DCC OpCode 340 (FIG. 4) and optionally a DCC sub-OpCodetype, length, and value 342 (FIG. 4) indicative of a particularmaintenance activity. For example, an Ethernet OAM frame can begenerated at the BRAS 612 including a Port Test Message for verifyingthe integrity of the DSLAM port.

FIG. 10 is a schematic diagram of one embodiment of an Ethernet OAMframe 300′″ using a sub-OpCode to initiate a Port Test. The Ethernet OAMframe 300′″ includes an Ethernet OAM PDU 302 having in its OpCode fieldan ETH-DCM 344 OpCode together with the appropriate ME Level (ME LVL)318 of a MEP within the access node 616 to establish the maintenancechannel 618. The application-specific portion 304 of the Ethernet OAMPDU 302 includes a sub-OpCode type, length, and value field 346 furtheridentifying that the message is requesting a Port Test at a particularport ID, associated with a particular circuit ID identified by theCircuit ID type, length, and value field 348. Other DCC type, length,and values 350 can be included in the port-test request, as necessary.

Referring again to FIG. 9, the MEP within the access node 616 receivesthe Ethernet OAM frame and identifies the Port Test Message. The MEPpasses the Ethernet OAM frame onto an OAM proxy, also provided withinthe access node 616 for processing the Port Test Message. Within theaccess node 616, the network side of the OAM proxy is accessed throughend-to-end Ethernet OAM messages. The user side of the OAM proxy (e.g.,looking out toward the DSL modems 602) can include other messages, suchas point-to-point Asynchronous Transfer Mode (ATM) messages, or Ethernet(EFM) OAM messages.

In some embodiments, the OAM proxy may initiate a complementary OAMprocedure on the DSL interface towards the subscriber. The OAM proxygenerates an appropriate Port Test Reply based on the results from anycomplementary OAM procedure and passes it to the MEP. These results mayinclude list of tests performed and status of those tests (e.g., G.992.7up, 1.610 LB fail, etc.). The MEP then sends the Ethernet OAM messageincluding the Port Test Reply to the BRAS 612 through the maintenancechannel 618.

FIG. 11 is a schematic diagram of one embodiment of an Ethernet OAMframe 300″″ using a sub-OpCode to initiate a Port Test Reply message.The Ethernet OAM frame 300″″ includes an Ethernet OAM PDU 302 having inits OpCode field an ETH-DCR OpCode 344 together with the appropriate MELevel (ME LVL) 318 of a MEP within the BRAS 612 to establish themaintenance channel 618. The application-specific portion 304 of theEthernet OAM PDU 302 includes a sub-OpCode type, length, and value field352 further identifying that the message is replying to a port testperformed at a particular port ID, further identified within by aCircuit ID type, length, and value field 354. Other DCC type, length,and values 356 can be included in the reply, as necessary.

FIG. 12 is a schematic diagram of an alternative embodiment of anEthernet OAM PDU 700 including within its OpCode field an EthernetMaintenance Communication Channel function identifier (ETH-MCC 740). TheETH-MCC can be used for providing a maintenance communication channelbetween a pair of MEPs 230 (FIG. 2B). The ETH-MCC function 740 can alsobe used to perform remote management. A MEP 230 can send a frame withETH-MCC information to its peer MEP 230 with remote maintenance request,remote maintenance reply, notification, etc. The exemplary Ethernet OAMPDU 700 includes an application-specific portion 704 optionallyproviding data related to the maintenance communication channel. Table 3identifies the different fields of the Ethernet OAM PDU 700 according tothe pre-published standard Y.1731 of the ITU, entitled “OAM Functionsand Mechanisms for Ethernet Based Networks” at the time of this filing.

Specific configuration information required by a MEP 230 to supportETH-MCC 740 includes a MEG Level (MEL 718) at which the MEP 230 exists;a unicast MAC address (Destination MAC 306) of the remote MEP 230 forwhich ETH-MCC is intended; an Organizationally Unique Identifier (OUI)714 used to identify the organization defining a specific format andmeaning of ETH-MCC; and optionally MCC Data 734 including any additionalinformation that may be needed and is dependent on the specificapplication (i.e., functionality) of ETH-MCC 740. Also provided withinthe Ethernet OAM PDU 700 is a Sub OpCode 742 containing a 1-octet fieldfor to interpreting the remaining fields in the optional MCC data 734 asmay be required, depending upon the functionality indicated by the OUI714 and organizationally specific SubOpCode 742. The optional MCC data734 may carry one or more TLVs.

TABLE 3 Fields of an Ethernet OAM PDU Ethernet OAM Field Description VER716 4-bit field identifying OAM protocol version MEL 718 4-bit fieldidentifying the administrative domain (i.e., the maintenance entitylevel) of the OAM frame (e.g., ranges from 0 to 7: ranges 0-2 identifyoperator domains; ranges 3-4 identify provider domains; and ranges 5-7identify customer domains). ETH-MCC 740 1-Octet field identifying thetype of OAM frame (e.g., ETH-MCC) FLAGS (0) 710 Set to all-ZEROes TLVOFFSET 712 1-byte field OUI 714 3-octet field that contains theOrganizationally Unique Identifier of the organization defining theformat of MCC Data and values SubOpCode SUB OPCODE 742 1-octet fieldthat is used to interpret the remaining fields in the MCC PDU OPTIONALMCC DATA Depending on the functionality indicated by the OUI 734 andorganizationally specific SubOpCode, MCC may carry one or more TLVs. ENDTLV 740 All-ZEROes octet value

A remote MEP 230, upon receiving a frame with ETH-MCC information andwith a correct MEG Level, passes the ETH-MCC information to themanagement agent which may additionally respond.

While the invention has been shown and described with reference tospecific preferred embodiments, it should be understood by those skilledin the art that various changes in form and detail may be made thereinwithout departing from the spirit and scope of the invention as definedby the following claims.

1.-25. (canceled)
 26. A method of operating a network element for use ina communications network supporting transmission of Ethernet protocoldata units, the method comprising: providing at least one maintenanceentity level identifier, each maintenance entity level identifier beingassociated with at least one termination maintenance entity; andgenerating at least one Ethernet protocol data unit, the at least oneEthernet protocol data unit comprising: content signifying that theEthernet protocol data unit comprises content related to OAM; and atleast one maintenance entity level identifier.
 27. A method as definedin claim 26, further comprising forwarding the at least one Ethernetprotocol data unit along a forwarding plane of the data communicationsnetwork.
 28. A method as defined in claim 27, further comprising:receiving Ethernet protocol data units from the data communicationsnetwork; identifying at least one received Ethernet protocol data unitcomprising content signifying that the Ethernet protocol data unitcomprises content related to OAM and content identifying a maintenanceentity level associated with at least one maintenance termination entitythat is to process the received Ethernet protocol data unit; andforwarding the at least one identified Ethernet protocol data unit to anOAM application when the network element has a maintenance entity levelcorresponding to the maintenance entity level identified in the receivedEthernet protocol data unit.
 29. A method as defined in claim 28,further comprising: generating at least one reply Ethernet protocol dataunit in response to the identified Ethernet protocol data unit, thereply Ethernet protocol data unit comprising: content signifying thatthe Ethernet protocol data unit comprises content related to OAM; andcontent identifying the maintenance entity level identified in theidentified Ethernet protocol data unit.
 30. A method as defined in claim26, wherein the Ethernet protocol data unit generator is operable togenerate at least one Ethernet Operation, Administration and Maintenance(OAM) frame.
 31. A method as defined in claim 30, wherein the step ofgenerating the at least one Ethernet protocol data unit comprisesgenerating the Ethernet protocol data unit to further comprise contentidentifying a functionality of the Ethernet data protocol unit.
 32. Amethod as defined in claim 31, wherein the step of generating the atleast one Ethernet protocol data unit comprises generating the at leastone Ethernet protocol unit with the content identifying a functionalityof the Ethernet data protocol unit identifying orderwire functionality.33. A method as defined in claim 31, wherein the step of generating theat least one Ethernet protocol data unit comprises generating the atleast one Ethernet protocol unit with the content signifying that theEthernet protocol data unit within a general portion of the Ethernetprotocol data unit and the content identifying the functionality withinan application-specific portion of the Ethernet protocol data unit. 34.A network element for use in a communications network supportingtransmission of Ethernet protocol data units, the network elementcomprising: a data store operable to store at least one maintenanceentity level identifier, each maintenance entity level identifier beingassociated with at least one termination maintenance entity; and anEthernet protocol data unit generator operable to generate at least oneEthernet protocol data unit, the at least one Ethernet protocol dataunit comprising: content signifying that the Ethernet protocol data unitcomprises content related to OAM; and at least one maintenance entitylevel identifier.
 35. A network element as defined in claim 34, furthercomprising an Ethernet protocol data unit forwarder operable to forwardthe at least one Ethernet protocol data unit along a forwarding plane ofthe communications network.
 36. A network element as defined in claim35, further comprising: an Ethernet procotol data unit receiver operableto receive Ethernet protocol data units from the communications network;at least one Ethernet protocol data unit processor operable to identifyat least one received Ethernet protocol data unit comprising contentsignifying that the Ethernet protocol data unit comprises contentrelated to OAM and content identifying a maintenance entity levelassociated with at least one maintenance termination entity that is toprocess the received Ethernet protocol data unit; and a channel agentoperable to forward the at least one identified Ethernet protocol dataunit to an OAM application when the network element has a maintenanceentity level corresponding to the maintenance entity level identified inthe received Ethernet protocol data unit.
 37. A network element asdefined in claim 36, wherein the Ethernet protocol data unit generatoris operable to generate at least one reply Ethernet protocol data unitin response to the identified Ethernet protocol data unit, the replyEthernet protocol data unit comprising: content signifying that theEthernet protocol data unit comprises content related to OAM; andcontent identifying the maintenance entity level identified in theidentified Ethernet protocol data unit.
 38. A network element as definedin claim 34, wherein the Ethernet protocol data unit generator isoperable to generate at least one Ethernet Operation, Administration andMaintenance (OAM) frame.
 39. A network element as defined in claim 38,wherein the Ethernet protocol data unit generator is operable togenerate the at least one Ethernet protocol unit to further comprisecontent identifying a functionality of the Ethernet data protocol unit.40. A network element as defined in claim 39, wherein the Ethernetprotocol data unit generator is operable to generate the at least oneEthernet protocol unit with the content identifying a functionality ofthe Ethernet data protocol unit identifying orderwire functionality 41.A network element as defined in claim 39, wherein the Ethernet protocoldata unit generator is operable to generate the at least one Ethernetprotocol unit with the content signifying that the Ethernet protocoldata unit within a general portion of the Ethernet protocol data unitand the content identifying the functionality within anapplication-specific portion of the Ethernet protocol data unit.
 42. Asystem for providing a data communications channel between at least twonetwork elements configured to support transmission of Ethernet protocoldata units over a communications network, the system comprising: a firstnetwork element comprising: an Ethernet protocol data unit generatoroperable to generate at least one Ethernet protocol data unit, the atleast one Ethernet protocol data unit comprising: content signifyingthat the Ethernet protocol data unit comprises content related to OAM;and content identifying a maintenance entity level associated with atleast one termination maintenance entity that is to process thegenerated Ethernet protocol data unit; and an Ethernet protocol dataunit forwarder operable to forward the at least one Ethernet protocoldata unit along a forwarding plane of the communications network; and asecond network element comprising: an Ethernet procotol data unitreceiver operable to receive Ethernet protocol data units from thecommunications network; at least one Ethernet protocol data unitprocessor operable to identify at least one received Ethernet protocoldata unit comprising content signifying that the Ethernet protocol dataunit comprises content related to OAM and content identifying amaintenance entity level associated with at least one maintenancetermination entity that is to process the received Ethernet protocoldata unit; and a channel agent operable to forward the at least oneidentified Ethernet protocol data unit to an OAM application when thenetwork element has a maintenance entity level corresponding to themaintenance entity level identified in the received Ethernet protocoldata unit.
 43. A system as defined in claim 42, wherein the secondnetwork element further comprises: an Ethernet protocol data unitgenerator operable to generate at least one reply Ethernet protocol dataunit in response to the identified Ethernet protocol data unit, thereply Ethernet protocol data unit comprising: content signifying thatthe Ethernet protocol data unit comprises content related to OAM; andcontent identifying the maintenance entity level identified in theidentified Ethernet protocol data unit.
 44. A method of providing a datacommunications channel between at least two network elements configuredto support transmission of Ethernet protocol data units over acommunications network, the method comprising: at a first networkelement: generating at least one Ethernet protocol data unit, the atleast one Ethernet protocol data unit comprising: content signifyingthat the Ethernet protocol data unit comprises content related to OAM;and content identifying a maintenance entity level associated with atleast one termination maintenance entity that is to process thegenerated Ethernet protocol data unit; and forwarding the at least oneEthernet protocol data unit along a forwarding plane of thecommunications network; and at a second network element: receivingEthernet protocol data units from the communications network;identifying at least one received Ethernet protocol data unit comprisingcontent signifying that the Ethernet protocol data unit comprisescontent related to OAM and content identifying a maintenance entitylevel associated with at least one maintenance termination entity thatis to process the received Ethernet protocol data unit; and forwardingthe at least one identified Ethernet protocol data unit to an OAMapplication when the network element has a maintenance entity levelcorresponding to the maintenance entity level identified in the receivedEthernet protocol data unit.
 45. A method as defined in claim 44,further comprising: at the second network element, generating at leastone reply Ethernet protocol data unit in response to the identifiedEthernet protocol data unit, the reply Ethernet protocol data unitcomprising: content signifying that the Ethernet protocol data unitcomprises content related to OAM; and content identifying themaintenance entity level identified in the identified Ethernet protocoldata unit.